昨天看過了Tempo的佈署架構
今天來看看它的DataFlow

Instrumentation

第一關就是負責捕獲跟產生trace data的Instrumentation, 通常是以Client libraray的形式
這點能參考Day17 淺談OpenTelemetry - Instrumentations

主要在這裡是用來建立與卸載Span

常見的有三種協議的Client instrumentation

• OpenTracing/Jaeger
• Zipkin
• OpenTelemetry

其中Jaeger這裡已經公告了, Client instrumentation要被棄用了

請轉去使用OpenTelemetry API, SDK和Instrumentation.
這裡能參考Day 6 淺談OpenTelemetry Client Library Architecture
其組件間的關係.

也有很多語言內建了一個機制叫做Auto-instrumentation.
它內建了一些必要的捕捉資訊, 讓client application這裡只需要最少的程式碼配置即可
Java
.Net
Python
這些都是OTel這裡提供的, 為各個語言盡量的提供.

Gafana Blog這裡也有提供Go的一個範

Agent

其實這個Agent主要是給使用Grfana Cloud的用戶用的.
提供了卸載Span到cloud的能力, 以及給個緩衝區處理Span們, 甚至批量處理.
通常Agent會以Sidecar形式在client application的附近

K8S架構的話可能就在同一個Node或同一個cluster內.

但其實吧!
上面的instrumentation都蠻多建議用OpenTelemetry了.
Agent, 建議也是別直接考慮Grafana Agent.
而是採用OpelTelemetry Collector.
都具備剛剛的能力!
能參考Day14 淺談OpenTelemetry - Collector
Day 15 淺談OpenTelemetry - Collector Compoents
Day 16 淺談OpenTelemetry - Collector Extensions

Backend(Tempo)

其實就是Tempo,
重複昨天提到的特性

easy-to-use and high-scale distributed tracing backend used to store and query traces.

Visualization (Grafana)

有了存儲跟查詢能力, 自然就要顯示它!
那就會推薦本家的工具Grafana了

Example Setups

能參考Day 26 Grafana - 為Log與Trace搭起一座鵲橋

或者Tempo也有提供Docker-Compose形式的安裝配置Repo連結

來看看提供的樣貌!!

用TraceID來查找

透過Log連查找

在Traces內根據條件搜尋

這個有限制

1. Grafana 需要8.2以上才有這功能讓你選
2. Tempo的設定檔要啟用搜尋Search
3. 它的實踐方式是搜尋Ingester內的資料, Ingester預設只會存儲近15分鐘內的traces data!
   

酷炫的APM Dashboard

今日小心得

有了Tempo, 突然視野變得寬闊多了:)

參考資料

Grafana Tempo